Two factor authentication using a one-time password

ABSTRACT

Methods and systems for online authentication eliminate the common username plus password combination, using instead a novel two-factor authentication that employs a mobile phone number and a one-time, limited life password. The user provides the mobile phone number to a login dialog and receives, from a service provider, the one-time password, e.g., via a text message, at the mobile device to which the phone number belongs. If the user enters the one-time password before it expires, the user is authenticated and logged in. A method for authentication or authorization to a website includes: receiving a phone number from a user via a communication network in response to a login prompt displayed to the user; transmitting a one-time password to the phone number using text messaging; and in response to receiving the one-time password back from the user, authenticating the user for transactions with the website.

BACKGROUND

1. Technical Field

Embodiments of the present invention generally relate to online commerceand social interactions conducted over a communication network such asthe Internet and, more particularly, to authentication for securecommunications, over the network, between service users and serviceproviders, including secure account access and authorizations.

2. Related Art

Secure communication over the Internet between parties to a transaction(e.g., an online shopper and a merchant website, or a user of a socialnetworking website and the social networking website) often relies onthe user registering on the website and then logging in to the websiteusing the familiar combination of a username and a password. Theusername-password login is one example of what is often referred to assingle factor authentication. The factors of authentication typicallyinclude: “something you have” (e.g., mobile phone or hardware token),“something you know” (e.g., personal identification number (PIN) orpassword), and “something you are” (e.g., biometric information). In theonline shopper example, an entity (the shopper, referred to as“end-user” or “user”) that wants to assert a particular identity maycommunicate some authentication information to another entity (themerchant website, referred to as “relying party” or “service provider”)that wants to verify the end-user's identity. Each service provider mayprovide their own system for login and authentication so that anyparticular user may need to register an identifier (e.g., username andpassword) at every service provider the user wishes to maintain anaccount or identity with.

OpenID is an open standard for authentication that allows users toconsolidate their digital identities and eliminates the need for serviceproviders to provide their own individual or ad hoc systems. OpenID mayprovide a user with one login for multiple sites. For example, a usermay create accounts with one or more of the user's preferred OpenIDidentity providers, and then use those accounts as the basis for signingon to any website which accepts OpenID authentication. The OpenIDstandard provides a framework for the necessary communication betweenthe identity provider and the OpenID relying party. An extension toOpenID—OpenID Attribute Exchange—facilitates the transfer from theOpenID identity provider to the relying party of certain userinformation, such as name and address, that may be requested by arelying party.

Similarly, OAuth is an open standard for authorization, complementaryto, but distinct from OpenID, that allows users to share privateinformation stored on one site with another site without having tocompromise identity credentials. Typically, OAuth supplies a token thatgrants access to a specific site for certain user information for aspecified period of time. This allows a user to grant a third party siteaccess to their information stored with another service provider,without sharing their access permissions or the full extent of theirdata.

The OpenID protocol does not rely on a central authority to authenticatea user's identity. Moreover, neither service providers nor the OpenIDstandard may mandate a specific approach to authenticating users,allowing for various approaches including username-password, smartcards, or biometrics. OpenID typically, however, uses the familiarusername and password authentication, which is prone to a number ofdisadvantages. For example, a quality password should have manycharacters which are a mix of upper, lower, punctuation, and specialcharacters so that it is difficult to compromise. However, a goodquality password is often difficult and time-consuming to type, is oftenforgotten (as various password requirements exist on various sites), andusers are advised to use different passwords for different accounts (tofurther reduce the chance their accounts will be compromised). This isespecially true on a mobile device using touch keypads that have various‘levels’ of keypads for characters beyond simple alpha-numeric. Thesedifficulties or “friction” perceived on the part of the user, howeverminor, may lead to certain compromises. For example, many users may beapt to use less than optimal passwords, and use them repeatedly, whichcan be vulnerable to many well-known types of attack, such as adictionary attack (a script that systematically tries out commonly usedpasswords) or trying out passwords which relate to the user (e.g. nameof child, spouse, pet, or important dates).

SUMMARY

According to one or more embodiments of the present invention, methodsand systems for authentication eliminate the common username pluspassword combination, instead using a novel two-factor authenticationthat employs a mobile phone number and one-time, limited life password.The user provides the user's mobile phone number to login to a serviceprovider's site, and receives a one-time password (e.g., via a textmessage) on the mobile device to which the phone number belongs. If theuser enters the one-time password within its limited lifespan, the useris then logged into the service provider's site.

In one or more embodiments, a system includes: a processor configured tocommunicate over a network with a mobile device and with a website; anda data storage device including a computer-readable medium havingcomputer readable code for instructing the processor, and when executedby the processor, performs operations including: receiving a phonenumber from a user via the network in response to a login promptdisplayed to the user; transmitting a one-time password to the mobilephone associated with the phone number; and in response to receiving theone-time password from the user via the network, authenticating the userfor transactions with the website.

In another embodiment, a method includes: receiving a phone number froma user via a network in response to a login prompt displayed to theuser; transmitting a one-time password to the phone associated with thephone number; and in response to receiving the one-time password fromthe user via a network, authenticating the user for transactions with awebsite.

In a further embodiment, a computer program product comprises anon-transitory computer readable medium having computer readable andexecutable code for instructing a processor to perform a method thatincludes: receiving a phone number from a user via a network in responseto a login prompt displayed to the user; transmitting a one-timepassword to a phone associated with the phone number; and in response toreceiving the one-time password from the user via the network,authenticating the user for transactions with the website.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram illustrating a system for providingauthentication services in accordance with an embodiment of the presentinvention.

FIG. 2 is a flow chart illustrating a method for providingauthentication services in accordance with an embodiment.

FIG. 3 is a flow chart illustrating a method for using authenticationservices in accordance with an embodiment.

FIG. 4 is a flow chart illustrating a method for providingauthentication for resetting passwords in accordance with an embodiment.

DETAILED DESCRIPTION

Embodiments of the present invention provide a two-factor authenticationthat replaces the commonly used username and password authenticationwith the user's phone number and transmission to the user's phone of alimited life, one-time password, which, for example, could be as simpleas a personal identification number (PIN) or more elaborate such as arandom string of upper and lower case characters, numbers, and specialcharacters. Briefly, from the user's perspective, the user goes to anonline website (e.g., a merchant or service provider) and logs in byentering the phone number for a mobile device the user has at hand, theuser promptly receives a message on the mobile device containing theone-time password, enters the one-time password to the online log inbefore it expires, and is then logged in to the online website. Limitedinformation (already selected by the user) may be shared with the onlinewebsite, for the purposes of user preferences, tracking, and ordermanagement.

Embodiments provide a two-factor authentication that is easier to use,and therefore, more secure than the typical username-passwordauthentication, because, for example, most people will remember theirphone number and the one-time password need not be remembered as it issent to the user in near real time and must be used within a very shortlifespan before it expires. Thus, embodiments alleviate commondifficulties with users having to remember a multitude of arbitraryusernames and corresponding passwords, which are often forgotten.Elimination of the “friction” described above, making embodiments morereadily used and more reliable, for example, may further enhance thesecurity of authentication provided by one or more embodiments so as tomitigate or eliminate the problem of “account takeover” experienced byservice providers, in which a user's account may be fraudulently used byan unauthorized person who manages to guess or break theusername-password security of an account owned by the user. Suchservices may include, for example, an online payment service operatingbetween consumers and merchants and may be a service provided by afinancial service provider (FSP)—such as PayPal, Inc. of San Jose,Calif.—in which a user of the service may have an account with the FSP(referred to as an “FSP account).

Embodiments may also provide convenient (e.g., one-stop login or use ofa favorite login provider for use with multiple merchants and websites)authentication and authorization services such as those provided byOpenID and OAuth. Embodiments may provide an added level of securitycompared to OpenID and OAuth, however, because the operational models ofOpenID and OAuth, and similar standards, may be described ashub-and-spoke, where the OAuth or OpenID account is the hub, and allrelated accounts are the spokes. If the hub is compromised (for example,via a weak password, phishing, or malware) then the spokes are alsocompromised. With the new mechanism for authentication provided by oneor more embodiments, there is little opportunity for compromise.

FIG. 1 illustrates a system 100 for online commerce according to oneembodiment. A user 102 (generally a consumer or consumer user of FSPservices) may communicate via a computing device 104 (e.g., a computer,cell phone, computing tablet, or other consumer electronic device) withfinancial service provider (FSP) 120 via communication networks 106,which may include the Internet as well as phone networks such as PublicSwitched Telephone Network (PSTN). User 102 may also communicate overcommunication networks 106 using a mobile device 105, e.g., a mobilephone of any kind, that can receive messages such as Short MessageService (SMS) messages. User 102 may also communicate via network 106with a website 108 that may be a merchant website that is a seller ofretail goods, for example. Merchant website 108 may sell goods onlineand may communicate with user 102, for example, by operating a server110 (e.g., a computer processor) that presents a website for sellinggoods. The server 110 may respond responding to client devices (e.g.,client 111 running on device 104) by communicating over network 106. Ingeneral, for purposes of embodiments described herein, computing device104 and mobile device 105 need not be separate devices, although theycan be, and may be the same device such as embodied by a smart phone,for example.

Merchant website 108 may also communicate (for example, using server110) with FSP 120 through FSP server 122 over network 106. For example,merchant website 108 may communicate with FSP 120 in the course ofvarious services offered by FSP 120 to merchant website 108, such aspayment intermediary between customers (e.g., consumer user 102) ofmerchant website 108 and merchant website 108 itself. For example,merchant website 108 may use an application programming interface (API)112 that allows it to offer sale of goods in which customers are allowedto make payment through FSP 120, while consumer user 102 may have anaccount with FSP 120 that allows consumer user 102 to use the FSP 120for making payments to sellers that allow use of authentication,authorization, and payment services 124 of FSP 120 as a paymentintermediary. Also as shown in FIG. 1, FSP 120 may provide electronicdata storage in the form of database 126. Database 126 may be used tokeep track of user's accounts 128 with FSP 120, merchant's accounts withFSP 120, and transactions between customers, merchants, and storesincluding payments between the various entities, for example. FSP server122 may execute various application programming interfaces (APIs) thatmay enable various different types of relationships between FSP 120 andthe different parties shown in FIG. 1. In addition, FSP may providevarious APIs 125 to its customers such as website 108 (e.g., API 112)and website 130 (e.g., API 112) that enable those websites to implementembodiments of authentication, authorization, and password resetservices.

Website 130 may be a website that provides authorization services thatenable a user (e.g., user 102) to login to other websites and serviceswhile only having to maintain one user account 134 at the authorizationservices website 130. For example, such an arrangement may be providedaccording to the OpenID and OAuth standards. Website 130 may communicatewith FSP 120 and user 102, for example, over communication network 106via server 136. Website 130 may offer authentication and authorizationservices through use and customization of an API 132 which may beprovided by FSP 120. For example, FSP 120 may provide an API 125 that iscustomizable to become API 132. Similarly, merchant website 108 mayoffer authentication and authorization services through use andcustomization of an API 125 that is customizable to become API 112provided by FSP 120.

FIG. 2 illustrates a method 200 for providing authentication services.In one embodiment a financial service provider may create (or otherwiseprovide) a series of API's for registration, login, or password reset(not all APIs may be needed by all customers, e.g., merchant websites orservice providers).

At step 201, a service provider (e.g., FSP 120) may provide an API(e.g., one of APIs 125) for registration to one of its commercialcustomers (e.g., merchant website 108 or authentication services website130) that, when customized by the customer, e.g., merchant website 108,may implement a merchant-customized registration flow (a web flow orexchange of communication between the website and a user, e.g., user102, of the website) that at the least gathers and verifies the user'smobile number. The merchant may integrate the API into the merchant'swebsite as an alternative to a traditional merchant-hosted registrationflow.

At step 202, a service provider may provide an API for user login thatwhen, customized by the customer, e.g., website 108 or 130, mayimplement a login web flow. For example, the customized API (e.g., API112 or 132) may implement a login dialog box—which may displayed fromthe merchant website 108, a website of FSP 120 or an authenticationwebsite 130 upon redirect, for example—that requires a mobile phonenumber, sends a one-time password via SMS to that mobile phone (by usingthe phone number sends the one-time password to the phone having thatphone number), then prompts the consumer to enter in the one-timepassword. Once completed, the consumer user (e.g., user 102) may beauthenticated and directed to the merchant website, e.g., website 108.

At step 203, a service provider may provide an API for user passwordreset (e.g., for conventional username-password authenticationprocesses) that when, customized by the customer, e.g., website 108 or130, may implement a customer-customized web flow. The password resetAPI could be useful for customers not wishing to use the registration orlogin API for one-time password authentication and preferring to staywith a more conventional username-password authentication process. Forexample, the customized API (e.g., API 112 or 132) may implement a webflow for helping consumer users (e.g., user 102) reset passwords basedon mobile phone numbers in their profile. In use, a consumer may enterthe consumer's existing username (e.g. email address is commonly used)and a phone number in a dialog box or separate frame of the webpage(e.g., an iframe could be used). The password reset API may then send,in response, a one-time password in a text message to the consumer'smobile phone via SMS, and the consumer would enter that one-timepassword back in the iframe. Once the consumer is authenticated, thepassword reset API would send a new password via SMS to the consumer,and notify the merchant of the new password. The merchant can present a“change your password” flow of its own choosing at this point.

At step 204, a service provider (e.g., FSP 120) may deliver anappropriate API (e.g., one of APIs 125) to its customer, e.g., merchantwebsite 108 or authentication service provider (login host website) 130.The API may be customized either before or after delivery.

FIG. 3 illustrates a method 300 for using authentication services inaccordance with an embodiment.

At step 301, a service provider (e.g., FSP 120 or login host website130) may receive a phone number from a user 102 via the network 106 inresponse to a login prompt displayed to the user 102. For example, theuser 102 may go to the merchant website 108 from any device (e.g.,computing device 104 or mobile device (phone) 105) and clicks “Sign in”(e.g., the displayed login prompt). It doesn't matter what device user102 signs in from (e.g., computing device 104 or mobile device (phone)105) because the session would eventually time out, and the one-timepassword that will be provided to and used by user 102 may prevent thesame credentials from being used again later for another session.

In an example of user 102 shopping on a merchant website 108, a numberof login options may be provided.

In a first login option example, FSP 120 may host the login. The FSP 120may provide computer code (e.g., an API 125) to the merchant website108, which the merchant website 108 may place on their website (similarto experience with OpenID or OAuth) for their customers to log in. Oncethe customer completes the login session, the FSP 120 may pass certaininformation (e.g., from accounts information 128) such as email addressand user identification so that the merchant website can trackinformation (e.g., preferences, items in cart) about this particularcustomer, consumer user 102.

In a second login option example, the user 102 can choose one of manyoptional login hosts. Some merchants (e.g., merchant website 108)present customers with multiple options for logging in, based onaccounts at companies the customer may already do business with, andwhich, importantly, they trust. For example, large companies or oneswith a well-known web presence that offer their own login accounts.Similar to the first login option example, once the customer completesthe login session via the chosen login host (e.g., using method 300 atlogin host website 130), FSP 120 may pass certain information (e.g.,email address and user identification) to the merchant website 108 sothe merchant can track information (e.g., preferences, items in cart)about this particular customer, consumer user 102.

In a third login option example, the merchant could have its own logindialog, but also offer an alternative for the FSP 120 login such as anadditional button to click.

Regardless of login option chosen, user 102 may enter the mobile phonenumber of the user's mobile device (e.g., phone number for mobile device105). For example, the user may enter the user's mobile device phonenumber in the field that asks for it and click “submit”.

At step 302, in the background and in response to receiving the phonenumber, FSP 120 may match the phone number to an FSP account (e.g.,using database 126 and accounts information 128). On finding a match,FSP 120 may generate a one-time password, set a pre-defined expirationperiod for the one-time password, and send the one-time password to thephone number (e.g., to the mobile device having that phone number suchas mobile device 105). The expiration period gives the one-time passworda finite lifespan, e.g., a few minutes, after which the one-timepassword expires, meaning that it is no longer valid and theauthentication process will not be continued, regardless of whether ornot the one-time password has been correctly entered. Also, for example,on finding a match, if the user's FSP account is suspended or under someother restriction, FSP 120 may provide a dialog to user 102 thatexplains the next steps for that user.

At step 303, user 102 may enter the one-time password (by entering inthe proper field in the dialog or web flow provided, for example, andclicking submit). In response to receiving the one-time password fromthe user 102 via the network 106 before the expiration period for theone-time password passes or runs out, the user 102 is now logged in(e.g., authenticated) and may start shopping, for example, on themerchant website 108. Because the login module (e.g., the login dialogand exchange of information with user 102) is hosted by the FSP 120,only FSP 120 (e.g., server 122, database 126) needs to look for thecorrect one-time password to be received and the one-time password doesnot need to be sent to the merchant website 108. If the user 102 failsto enter the correct one-time password, FSP 120 may provide a dialogthat either prompts the user 102 to enter the one-time password again orprovides an option like “click to resend one-time password”. Once user102 enters in the correct one-time password, FSP 120 may pass certaindata elements to the merchant website 108 so that it can track thesession, information, and preferences of user 102 for the merchantwebsite's product, service, or company.

For example, by logging in with FSP 120, one of the data elements sharedwith merchant website 108 may be a unique identifier generated by theFSP—e.g., a random string such as “123a4b56c789d”—that represents theuser's (e.g., user 102) FSP account. With the FSP-unique identifier, themerchant website 108 may be able to associate any number of differentthings (e.g., display preferences, items in the user's cart, favoriteitems, wish lists) with the user's FSP-unique identifier. The merchantwebsite 108 may store this associated information as profileinformation, but the user (e.g., user 102) will not need to knowanything other than the user's mobile number (and the one-time passwordjust received) in order to log in to the merchant website (for example,the user does not need a merchant website username and passwordcombination). Thus, the user may be relieved of many of the problems anddifficulties discussed above and may experience very little “friction”(as defined above) for logging in to the merchant website. The loginprocess may still, however, provide the merchant website with theinformation it desires to have about the user (e.g., user 102) who islogging in using method 300.

FIG. 4 illustrates a method 400 for providing authentication forresetting passwords in accordance with an embodiment. At step 401, anoperator of a customized API for resetting passwords (e.g., FSP 120,merchant website 108, or login host website 130) may receive an existingusername or email address and phone number from, for example, a merchanton behalf of a consumer user 102 via the network 106 in response to apassword reset prompt displayed to the user 102. For example, operatorFSP 120 may provide a web flow for helping consumer users (e.g., user102) reset passwords based on mobile phone numbers in their profile(e.g., accounts information 128). The consumer 102 may enter theconsumer's existing username (e.g. email address is commonly used) and aphone number in a dialog box or separate frame of the webpage.

At step 402, continuing with the same example, FSP 120 may send, inresponse to receiving the username and password, a one-time password(having a pre-defined lifespan or expiration period, after which theone-time password is no longer valid for authentication) in a textmessage, using the phone number (e.g., to the device associated with thephone number), to the consumer user's (user 102) mobile device. Theconsumer may be expected to then enter that one-time password back intothe dialog box or separate frame of the webpage. At step 403, inresponse to receiving the one-time password back from the user 102 viathe network 106, the user may be authenticated, e.g., transactions andoperations requiring authentication or authorization may now proceed.

At step 404, once the consumer user 102 is authenticated, the FSP 120may (by executing the password reset API) may either allow the user toestablish a new password on the merchant website or send a new password(for use with the username) in a text message (e.g., via SMS) to theconsumer user 102, and notify the customer (e.g., merchant website 108)of the new password. The merchant website 108 may present a “change yourpassword” flow at this point. The “change your password” flow may havebeen chosen, designed, or customized by the merchant website to suit itswishes.

In implementation of the various embodiments, embodiments of theinvention may comprise a personal computing device, such as a personalcomputer, laptop, PDA, cellular phone or other personal computing orcommunication devices. The payment provider system may comprise anetwork computing device, such as a server or a plurality of servers,computers, or processors, combined to define a computer system ornetwork to provide the payment services provided by a payment providersystem.

In this regard, a computer system may include a bus or othercommunication mechanism for communicating information, whichinterconnects subsystems and components, such as a processing component(e.g., processor, micro-controller, digital signal processor (DSP),etc.), a system memory component (e.g., RAM), a static storage component(e.g., ROM), a disk drive component (e.g., magnetic or optical), anetwork interface component (e.g., modem or Ethernet card), a displaycomponent (e.g., CRT or LCD), an input component (e.g., keyboard orkeypad), and/or cursor control component (e.g., mouse or trackball). Inone embodiment, a disk drive component may comprise a database havingone or more disk drive components.

The computer system may perform specific operations by processor andexecuting one or more sequences of one or more instructions contained ina system memory component. Such instructions may be read into the systemmemory component from another computer readable medium, such as staticstorage component or disk drive component. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the invention.

Logic may be encoded in a computer readable and executable medium, whichmay refer to any medium that participates in providing instructions tothe processor for execution. Such a medium may take many forms,including but not limited to, non-volatile media, volatile media, andtransmission media. In one embodiment, the computer readable medium isnon-transitory. In various implementations, non-volatile media includesoptical or magnetic disks, such as disk drive component, volatile mediaincludes dynamic memory, such as system memory component, andtransmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise bus. In one example, transmissionmedia may take the form of acoustic or light waves, such as thosegenerated during radio wave and infrared data communications.

Some common forms of computer readable and executable media include, forexample, floppy disk, flexible disk, hard disk, magnetic tape, any othermagnetic medium, CD-ROM, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, RAM, ROM,E2PROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave,or any other medium from which a computer is adapted to read.

In various embodiments, execution of instruction sequences forpracticing the invention may be performed by a computer system. Invarious other embodiments, a plurality of computer systems coupled by acommunication link (e.g., LAN, WLAN, PTSN, or various other wired orwireless networks) may perform instruction sequences to practice theinvention in coordination with one another.

Modules described herein can be embodied in one or more computerreadable media or be in communication with one or more processors toexecute or process the steps described herein.

A computer system may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through a communication link and a communication interface.Received program code may be executed by a processor as received and/orstored in a disk drive component or some other non-volatile storagecomponent for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa—for example, a virtual Secure Element (vSE) implementation ora logical hardware implementation.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readable andexecutable mediums. It is also contemplated that software identifiedherein may be implemented using one or more general purpose or specificpurpose computers and/or computer systems, networked and/or otherwise.Where applicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure. Having thus described variousexample embodiments of the disclosure, persons of ordinary skill in theart will recognize that changes may be made in form and detail withoutdeparting from the scope of the invention. Thus, the invention islimited only by the claims.

What is claimed is:
 1. A system comprising: a non-transitory memorystoring machine-readable data; and one or more hardware processorscoupled to the non-transitory memory and configured to communicate overa network with a mobile device of a user and with a plurality ofwebsites and configured to read instructions from the non-transitorymemory to cause the system to perform operations comprising: displayinga login prompt to the user at a merchant website from the plurality ofwebsites; receiving a phone number from the user having an account witha financial service provider (FSP), via the network, in response to thelogin prompt; transmitting a one-time password to a mobile phone usingthe phone number; and in response to only receiving the one-timepassword from the user via the network, authenticating, by the FSP, theuser with the merchant website; sharing, with the merchant website,profile information about the user from the user's account with the FSP,including a unique identifier generated by the FSP that represents theuser's account with the FSP, wherein the profile information isassociated with the unique identifier generated by the FSP; logging theuser directly into the merchant website based on the profile informationand the unique identifier; and logging the user, from the merchantwebsite, into a second website of the plurality of websites based on theprofile information and the unique identifier without further use of theone-time password or phone number.
 2. The system of claim 1, wherein theone-time password is not sent to the merchant website.
 3. The system ofclaim 1, wherein the login prompt is displayed on a login host website.4. The system of claim 1, wherein the one-time password has predefinedexpiration period, after which the processor does not authenticate theuser in response to receiving the one-time password.
 5. The system ofclaim 1, wherein receiving the phone number comprises receiving thephone number via the network from a device displaying the login prompt.6. The system of claim 1, wherein the one-time password is transmittedusing short message service (SMS) texting to a device having the phonenumber.
 7. The system of claim 1, wherein receiving the one-timepassword comprises receiving the one-time password via the network froma device displaying the login prompt.
 8. The system of claim 1, whereinreceiving the one-time password comprises receiving the one-timepassword via the network from a phone to which the one-time password wastransmitted.
 9. A method comprising: displaying a login prompt to a userat a merchant website; receiving a phone number from the user having anaccount with a financial service provider (FSP), via a network, inresponse to the login prompt; transmitting a one-time password using thephone number; and in response to only receiving the one-time passwordfrom the user via the network, authenticating, by the FSP, the user withthe merchant website; sharing, with the merchant website, profileinformation about the user from the user's account with the FSP,including a unique identifier generated by the FSP that represents theuser's account with the FSP, wherein the profile information isassociated with the unique identifier generated by the FSP; logging theuser directly into the merchant website based on the profile informationand the unique identifier; and logging the user, from the merchantwebsite, into a second website based on the profile information and theunique identifier without further use of the one-time password or phonenumber.
 10. The method of claim 9, wherein the one-time password is notsent to the merchant website.
 11. The method of claim 9, furthercomprising displaying the login prompt on a login host website.
 12. Themethod of claim 9, further comprising: setting an expiration period forthe one-time password, wherein: after the expiration period has passed,authentication of the user fails.
 13. The method of claim 9, whereinreceiving the phone number comprises: receiving the phone number via thenetwork from a device displaying the login prompt.
 14. The method ofclaim 9, wherein receiving the one-time password comprises: receivingthe one-time password via the network from a device displaying the loginprompt.
 15. A non-transitory machine-readable medium having storedthereon machine-readable instructions executable to cause a machine toperform operations comprising: displaying a login prompt to a user at amerchant website; receiving a phone number from the user having anaccount with a financial service provider (FSP), via a network, inresponse to the login prompt; transmitting a one-time password using thephone number; and in response to receiving only the one-time passwordfrom the user via the network, authenticating, by the FSP, the user withthe merchant website; sharing, with the merchant website, profileinformation about the user from the user's account with the FSP,including a unique identifier generated by the FSP that represents theuser's account with the FSP, wherein the profile information isassociated with the unique identifier generated by the FSP; logging theuser directly into the merchant website based on the profile informationand the unique identifier; and logging the user, from the merchantwebsite, into a second website based on the profile information and theunique identifier without further use of the one-time password or phonenumber.
 16. The non-transitory machine-readable medium of claim 15wherein the one-time password is not sent to the merchant website. 17.The non-transitory machine-readable medium of claim 15 furthercomprising machine-readable instructions executable to cause the machineto perform operations comprising: displaying the login prompt on a loginhost website.
 18. The non-transitory machine-readable medium of claim 15further comprising machine-readable instructions executable to cause themachine to perform operations comprising: setting an expiration periodfor the one-time password, wherein: after the expiration period expires,the processor does not authenticate the user in response to receivingthe one-time password.
 19. The non-transitory machine-readable medium ofclaim 15 further comprising machine-readable instructions executable tocause the machine to perform operations comprising: transmitting theone-time password using short message service (SMS) texting to a devicehaving the phone number.
 20. The non-transitory machine-readable mediumof claim 15 further comprising machine-readable instructions executableto cause the machine to perform operations comprising: receiving theone-time password via the network from a phone to which the one-timepassword was transmitted.